<!DOCTYPE HTML>
<html lang="en">
<head>
<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2008. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta charset="utf-8">
<title>Team Support for Logical Model Integration</title>
<link href="../book.css" type="text/css" rel="stylesheet">
</head>

<body>
<h1>Team Support for Logical Model Integration</h1>
<p>There are two viewpoints of interest when describing the Team support for logical 
  model integration:</p>
<ul>
  <li><em>Repository Provider</em>: A Repository Provider is the connection between 
    the local workspace and a remote repository. Details of the logical model 
    support from the standpoint of a Repository Provider can be found in the <a href="team_model_repo.htm">Repository 
    Roadmap for Logical Model Integration</a>.<br>
  </li>
  <li><em>Model Provider</em>: A Model Provider is the tooling that allows the 
    user to work with the model elements that are stored in the resources in the 
    local workspace. Details of how Model Providers can leverage this support 
    is found in <a href="team_model_model.htm">Model Roadmap for Logical Model 
    Integration</a>.</li>
</ul>
<p>The following points summarize the features covered by the Team logical model 
  support.</p>
<ul>
  <li>Maintaining Workspace Consistency: Operations performed directly on resources 
    may have undesirable side effects on model elements that are persisted in, 
    or are otherwise associated with, those resources. Clients can use the ResourceChangeValidator 
    to validate that changes to resources will not have undesirable side effects 
    on models while models can implement the ModelProvider#validateChange method 
    to validate a resource change.<br>
  </li>
  <li>Team Operations and Decorations: It has always been possible to have team 
    operations and decorations appear on model elements that have a one-to-one 
    relationship by adapting the model element to the corresponding IResource. 
    It is now possible to have operation and decorations appear on model elements 
    that have more complex relationships to resources by adapting a model element 
    to a ResourceMapping.<br>
  </li>
  <li>Semantic Merges of Model Elements: Model Providers can participate in headless 
    merges by associating an IStorageMerger with a particular file type, if there 
    is a one-to-one correspondence between model elements and resources. For more 
    complex relationships, Model Providers can adapt their ModelProvider to an 
    IResourceMappingMerger to have access to the full content of the merge operation.<br>
  </li>
  <li>Model participation in team viewers: The team views now make use of the Common Navigator
  framework. By extending a Common Navigator extension point and a Team extension point, and supplying a content
  provider and a label provider, a Model Provider can appear in the team views. With a few more additional
  steps, it is also possible to provide Merge Preview support for a model.
    <br>
  </li>
  <li>Remote Discovery: Model Providers can participate in Remote Discovery through the use of
  the Team ProjectSetCapability class to obtain an URI from project set entries. This URI can then
  be used with the Eclipse File System API to access remote contents.
  </li>
  <li>Model History: Model Providers can access individual File History through the FileHistory API, and present a
  model history  as they wish in a custom History Page which get displayed in the History View. </li>
  
</ul>
</body>
</html>
